-
Notifications
You must be signed in to change notification settings - Fork 911
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTLC blinded route support (EXPERIMENTAL) #3623
HTLC blinded route support (EXPERIMENTAL) #3623
Conversation
835a9d5
to
8c960cd
Compare
I did a quick pass on this, nothing looks too weird but my C skills are quite rusty (bad pun intended). On the proposal itself, there are three main areas on which I'd like more eyes on:
I turned my blinded path into a draft PR so that others can start having a look at it: lightning/bolts#765 |
I have a very rough prototype for eclair here: https://github.com/ACINQ/eclair/tree/route-blinding |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
commit 8c960cd is showing as empty/contentless for me?
Because the best code is no code at all |
Signed-off-by: Rusty Russell <[email protected]>
…ing. All NULL for now. Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
Everyone should return this for any HTLC error when they're handed a blinding alongside the HTLC. Signed-off-by: Rusty Russell <[email protected]>
…short_channel_id. This requires us to call ecdh() in the corner case where the blinding seed is in the TLV itself (which is the case for the start of a blinded route). Signed-off-by: Rusty Russell <[email protected]>
Huh... not sure how that happened. That's why backups FTW, one moment... |
Note that it's channeld which calculates the shared secret, too. This minimizes the work that lightningd has to do, at cost of passing this through. We also don't yet save the blinding field(s) to the database. Signed-off-by: Rusty Russell <[email protected]>
This will be used when we want to specify these in a route. But for now, they only alter gossipd, which always sets them to NULL. Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
This is what we expect in an enctlv used for htlcs. Signed-off-by: Rusty Russell <[email protected]>
…RIMENTAL) This is what actually lets us pay blinded invoices. Unfortunately, our internal logic assumes every hop in a path has a next `short_channel_id`, so we have to use a dummy. This is sufficient for testing, however. Signed-off-by: Rusty Russell <[email protected]>
8c960cd
to
74c1f9e
Compare
ACK 74c1f9e |
experimental means no changelog required. |
This is an implementation of https://github.com/lightningnetwork/lightning-rfc/blob/route-blinding/proposals/route-blinding.md (only with --enable-experimental-features).
In this method, the vendor provides a blinded path similar to route hints, but the node ids are blinded, and instead of short_channel_ids for each hop, it provides an encrypted blob. This can be used for (finally, genuinely!) private channels as well as fully private vendor paths. Every node on the blinded path needs to be upgraded, however.
This is the minimum implementation to allow interop testing (e.g. with @t-bast when he gets Eclair done). There are five things remaining to be done:
It's probably premature to add those until we have a solid spec (esp. how to encode blinded routes in bolt11; presumably this will involve emojis!).
Changelog-None: Experimental only